random_forum_fightfandomcom-20200214-history
User blog:Alpha654/The Theory of Everything in Geometry Dash
So, while I was away from the Wiki, I decided to try and figure out how the game actually works (out of boredom). I created a testing world where I could slowly move map components towards the cube until they exhibited an effect on the cube, and one by one, I found out exactly how things work in the game. This Theory of Everything that I have created is not only a reference to the level of the same name, but is also a collection of the results that I have managed to collect from all these tests. Let's begin, shall we? ---- The Theory of Everything in Geometry Dash by Alpha654 ---- 'Contents of Version 4.02:' *The Player's Position *Walls, Floors and Ceilings *Measuring Hitboxes *The Floor *Spikes *Blocks *Coins *Portals *Antigravity Interactions *Mini Interactions *Other Form Interactions *Resized Interactions *Bugs ---- 'The Cube's Position' First things first, what exactly is the cube's position? Most people would say that the cube's position is the same size and at the same position as the visible cube. It seems like the best answer due to how the cube seems to interact with map components in normal gameplay, doesn't it? Unfortunately, this "Cube Position" theory is actually highly unlikely to be true. There are two major pieces of evidence for this, the first being the size of hitboxes. If you determine a spike's hitbox with the Cube Position theory, you will notice that it is unusually small. It is highly unlikely that RobTop would have created a spike like this. The second piece of evidence against the Cube Position theory is that there is an error in the hitbox of a block, one that would have been too large to go unnoticed if the Cube Position theory were true. We will talk about this hitbox error soon. So the position of the cube cannot be the same thing as the visible cube. Instead, the cube's position is a point at the very center of the cube, which we will call the "Point Position" theory. The Point Position theory solves both of the problems of the Cube Position theory: The hitboxes of map components are now reasonably sized, and the hitbox error can actually exist. Now, there are still a couple of possible locations for the position of the cube. Specifically, the bottom of the cube and the center of the cube can be used for the player's position. I'm going to be assuming that the player's position is at the center of the cube, based on the fact that the trail that spawns behind the player in the editor originates from there. 'Walls, Floors and Ceilings' Blocks in Geometry Dash are not just blocks. They are composed of different types of hitboxes. My research has been able to come up with four distinct types of hitboxes: *'Floors. ' **If the player is inside of a floor hitbox, then they are automatically moved up to the top of the floor hitbox. **The wave does not interact with floors. *'Ceilings. ' **If the player moves upwards into a ceiling hitbox, they will be snapped to its bottom. **If the player moves laterally or downwards into a ceiling hitbox, they will not be affected by it. **The cube, robot and spider forms do not interact with ceilings, unless the H object is applied to the block. **The wave does not interact with ceilings. *'Walls. ' **If the player is inside of a wall hitbox, they will be destroyed. It is possible that a similar hitbox exists and is given to obstacles, but it is unlikely. **If the D object is applied to the block, the wave will be able to interact with a wall without being destroyed, so long as it does not enter the block's hitbox laterally. *'Triggers. ' **If the player is inside of a trigger, it will activate the component that it is assigned to. Some triggers require the player to make an input in order to activate them. That is almost all the information there is about hitboxes. There does, however, exist a glitch involving the cube (or certain other forms) to enter a floor hitbox and a wall hitbox at the same time, causing it to stop moving for an unknown reason. Because the glitch requires the player to enter a wall hitbox, the player will usually be destroyed if they attempt to perform this glitch, but the Ignore Damage feature and Noclip allow the player to enter such hitboxes unharmed. As a result, This glitch has been used as an "anti-noclip" device. I have been able to take this glitch even further. Using this setup with only one of the dual cubes, I have found that the second cube does not stop with the first cube. Furthermore, moving the setup out of the way will cause the affected cube to continue on like nothing ever happened. This means it is possible to separate dual cubes without the use of 2.2 features, although it requires Ignore Damage or Noclip to work. If only we could find a way to reproduce this effect without having to use a wall... 'Measuring Hitboxes' Figuring out the exact dimensions of object hitboxes will require measuring them. This, of course, means that we're going to need a standard unit to measure hitboxes with. I've decided that one unit will be equal to 1/60 of a block, which is the smallest amount a block can be moved precisely using the editor. 'The Floor' Now that we know what the hitboxes that make up everything are, we can start talking about what hitboxes everything uses. The floor of the map can be determined easily, simply by using teleportation portals. If we place a teleportation portal in the air and another below the floor, we can see that the cube is placed under the floor for a frame or two and immediately teleported back to the surface. This allows us to deduce that the floor of the map is one giant floor hitbox. Now, since we're assuming that the player's position is at the center of the cube, we can assume that the Floor's hitbox extends 30 units above the visible Floor. 'Spikes' A spike is composed of a wall hitbox that is around 73 units wide and 81 units tall. Fairly easy. Let's move on to something more complex... 'Blocks' A block is composed of a floor hitbox around 114 units wide and 16 units tall, which is directly above a wall hitbox 72 units wide and _ units tall, which is directly above a ceiling hitbox that is 114 units wide and _ units tall. But we're not moving on yet. There is actually a tiny gap between the floor hitbox and the wall hitbox! This gap is very small, and may be less than a unit in height. Nevertheless, it can be used by a precisely placed dash orb or floor hitbox. I might be the first to discover this. 'Coins' User coins (and probably secret coins as well) consist of a trigger hitbox 140 units wide and 138 units tall. The trigger hitbox will collect the coin upon activation. I've yet to figure out the true hitbox of other collectibles, such as mini coins. 'Portals' Portals are 125 units wide and 228 units tall. The trigger hitbox will perform different effects depending on the portal, but the portal's size should remain the same (Only gravity and form portals have been tested so far). Speed portals, however, have different hitboxes which have not yet been measured. 'Antigravity Interactions' The most likely theory is that when the player is under the effects of antigravity, they will interact with ceilings as if they were floors, and with floors as if they were ceilings. This is supported by how difficult it would be to implement the dual mode otherwise. 'Mini Interactions' Object hitboxes appear to be slightly smaller when the player is under the effects of the mini mode. Will test further to determine the new hitboxes. 'Other Form Interactions' Object hitboxes remain the same if the player uses different forms, with a few exceptions. As stated before, some forms do not interact with ceilings. Specifically, the cube, wave, robot and spider forms do not interact with ceilings, and will instead go straight through them as if they weren't there. Furthermore, the wave form does not interact with floors, either. 'Resized Interactions' The hitboxes of some objects, such as thorns, seems to stay the same after being resized. This can lead to some potential problems, such as the ability to pass straight through the gaps left in these objects. For other objects, such as blocks, their hitbox needs ''to scale with their size, and it can't be done by just scaling the hitbox. ''I do not yet know the exact details of this. 'Bugs' Now, for my favorite part. Because of the way the game works, there are a few bugs that sometimes come up. I've been able to find an explanation for why many of these bugs are in the game. Here is a list of the bugs that I know and explanations for how they work. *'Hitbox Gap.' **I've already gone over this one. The wall and floor hitboxes for normal block objects are separated by a gap less than one unit apart. It's incredibly difficult to use this unless the level you're playing is designed to abuse this glitch. *'Ignored Side Hitboxes' **Some players have experienced a glitch where they fly the ship slightly lower than the top of a floor hitbox (or slightly higher than the bottom of a ceiling hitbox), and the ship partially clips into the block. **This is simply because the ship does not interact with these hitboxes when it enters them from the side. *'Follow Player Y Desync' **After an object is set to follow the player's Y coordinate for an extended period of time, it will start to become desynced. **This starts to happen every single time the player lands on an object. The reason for this is because the player's position may be updated every time they interact with a floor hitbox, but any objects following it will not be updated the same way. *'Mini Wave Wall Clip' **A lesser-known glitch where the player can go through a wall if they are currently in the mini wave form and the wall (and floor) have the D object applied to them. **I do not yet have a full explanation for this glitch, but it is likely that the D object changes the block's hitbox in some way. This would require the resulting wall hitbox to be less than one block in height. *'Unresponsive Editor Mode' **Sometimes, after you play-test a level in the editor mode, the editor will become unresponsive and you will only be able to click on certain buttons (including the editor menu and the Save and Exit button, thankfully). Normal function is restored upon exiting the editor mode. **This effect occurs when you hold the screen (I am referring to "the screen" as any part of the screen that isn't one of the buttons) and tap the play-test button at the same time, then release the screen before you stop play-testing. ***The game doesn't pick up on certain inputs on the screen while play-testing, and also doesn't pick up on a hold input on the screen while there already is such an input; when you perform this glitch, the game thinks you're still holding the screen, and won't pick up any other inputs on it. ***This effect can be reversed if you play-test the level again, then hold the screen and stop play-testing the level at the same time. *''This bug isn't related to hitboxes, but I'll leave it here for now, since I feel it might be important. I'm probably going to put this entire section into a separate blog post dedicated to bugs.'' ---- To Do: *Test more objects, such as orbs, sawblades and speed portals. Category:Blog posts